1. Field of the Invention
The present invention relates to an apparatus and method for remote controlling, and more particularly, to an apparatus and method allowing remote controlling between a client and a server.
2. Description of Related Art
Protocols used for controlling a computer at a remote location include, among others, VNC (Virtual Network Computing) and RDP (Remote Desktop Protocol).
A basic concept of these protocols enables the output and input devices of a computer at a user location to be used like the output and input devices of a computer at a remote location. For implementing this protocol, it is necessary to reproduce a screen of a computer at a remote location on a screen of a computer at a user location.
FIG. 1 is a view for describing how a conventional remote control apparatus operates.
Referring to FIG. 1, the conventional remote control apparatus includes a client 1 and a server 2. A computer at a user location is called a Client since it sends a display update request, and a computer at a remote location is called a Server since it provides display information in response to the display update request. Hereinafter, the computer at the user location is referred to as a client and the computer at the remote location is referred to as a server.
A user performs desired control operations (for example, keyboard inputs, mouse clicks, etc.) while viewing a screen of the server 2 reproduced on a screen of the client 1. Control information according to the user's control operations is transmitted to the server 2 via a network. The server 2 processes this control information and transmits information of a changed screen as the processed result to the client 1 via the network. In a VNC protocol, a client for remote controlling is called a “Thin Client,” which is a client that reduces its size and weight for portability and only has indispensable functions for remote controlling in order to reduce cost. A remote control protocol for the thin client, such as VNC, is a communication standard allowing the interchange of display information and control information between the client 1 and the server 2. The remote control protocol for the thin client mainly consists of transmitting a display update request and control information from the client 1, and transmitting display information from the server. The client's capability for reproducing a screen of the server 2 depends on the network speed between the server 2 and the client 1, processing capacities of the server 2 and the client 1, effectiveness of data interchange, etc. To reduce the amount of data transmission between the server 2 and the client 1, encoding/decoding can be used. In this case, the server 2 includes an encoder and the client 1 includes a decoder. However, since the thin client generally has only indispensable functions, such an encoding/decoding method accompanying a large amount of calculations is not adopted therein. Instead, contents contained in a frame buffer of a server are transferred to a client, which is called “Raw Encoding” or very simple encoding/decoding, for example, “Copy Rectangle Encoding” is used.
FIG. 2 is a view for describing a display update method according to a conventional remote control protocol.
Referring to FIG. 2, a screen of a client 1 is updated according to a conventional remote control protocol as follows.
If the client 1 is connected to a server 2 via a network and basic data is interchanged between the client 1 and the server 2, the client 1 sends a display update request to the server 2 periodically or when an input event is generated. The server 2 transmits display information to the client 1 in response to the display update request. The client 2 reproduces a screen of the server 2 on its own display panel using the display information. At this time, the display update request is not always in a one-to-one correspondence with the display information transmission. That is, the server 2 can transmit the display information in response to a display update request, can transmit the display information in response to a specified set of display update requests, or can ignore the display update requests, according to its discretion. If the client 1 sends no display update request, the server 2 transmits no display information.
FIG. 3 shows a format of a display update request message according to a conventional remote control protocol.
Referring to FIG. 3, a display update request message according to VNC (Virtual Network Computing), a conventional remote control protocol, includes an incremental field, screen location fields (x-position and y-position), and screen size fields (width and height).
A client 1 requests display updating using the display update request message of FIG. 3. The client 1 designates the location and size of a screen to be updated, and designates whether the entire area of the screen should be updated or whether only a specified portion (to be changed) of the screen should be updated, using the incremental field.
FIG. 4 shows a format of a display information message according to a conventional remote control protocol.
Referring to FIG. 4, a display information message according to VLC, as a conventional remote control protocol, includes screen location fields (x-position and y-position), screen size fields (width and height), an encoding type field, and a display information field.
If a client 1 receives the display information message from a server 2, the client 1 checks values recorded in the screen location fields and the screen size fields of the display information message, decides an area of a screen to be updated, and displays the values recorded in the display information field on the decided area. If a value recorded in the encoding type field of the display information message represents raw encoding, the client 1 copies the value recorded in the display information field to its own frame buffer to reproduce a screen of the server 2. If a value recorded in the encoding type field represents encoding, the client 1 performs decoding and stores the decoded value in its own frame buffer, thereby reproducing a screen of the server 2.
As described above, since the client 1 receives only display information for a requested area from the server 2, the conventional remote control method has the following problems. First, in the client 1, a user can designate a specific area and request display updating only for the specific area, however, it is inconvenient in that the user him/herself must designate areas to be updated individually. Furthermore, whenever a window in an area to be updated moves to another location, the user should redesignate the area. Second, since the client 1 has no information for applications being operated in the server, the client 1 cannot provide to the server 2, reference information regarding how frequently a window screen should be updated for each application. For example, when a moving image is being reproduced on a window of an application being operated in the server 2, the client 1 should request display updating very frequently. If the operating application is an application for responding to a user input, the client 1 requests display updating only whenever there is the user input. However, in the conventional technique, since display updating is requested whenever there is a user input or per a specified period, the display update frequency is too low to reproduce moving images and is too high to reproduce still images. Therefore, in a case of reproducing moving images, smooth reproduction cannot be achieved, and in a case of reproducing still images, the same screen as the previous screen can be repeatedly updated. Third, a display update request for a specific portion of a screen is allowable, however, it is impossible to stop display updating. For example, when a user of a client 1 controls a certain application and a window of the application covers a portion of a screen, it is nearly impossible to send a request to stop updating the covered portion to the server 2. Fourth, when two applications are being operated in the server 2, it is assumed that a user of the client 1 takes an interest in one application and no interest in the other application. In this case, the client 1 will focus all its resources on the application of the user's interest and will process the other application if any remaining resources exist. In the conventional technique as described above, it is impossible to allocate resources to each application according to a user's designation.